Fatal error: Out of Memory

Philjb,

Thanks for reading my thread on this and your feedback. Much appreciated. I do need to do some further investigation on the issue as it has a significant impact on the type of implementation. (Time is my constraint at the moment as I have limited bandwidth to do the “deep dives” required).

Perhaps you have eluded to this in some of your comments, but is there away for Influxdb to diversify its memory needs by spanning both RAM and Storage space, so these “complex” queries can basically take what they need to complete (in terms of temporary memory)? Also, is there a “graceful” way the service could be configured so that the service does not stop when a “rougue” query is run? In addition (and this may be too much to ask), but is there a way for the service to return some sort of error response indicating that a query was too expensive to run based on resources available on the service?

I should give you some better context around the “stress test” I am referring to.

Presentation Layer: Grafana Times series Ingestion Rate: Data is being stored at a one second sample rate into Influxdb data Queries: A total of eight (8) different Tags are being selected using query like this over a 30 Day period. SELECT max(“value”) FROM “CPU” WHERE (“tagname” = ‘temperature’) AND timeFilter GROUP BY time(__interval) fill(null) Note: Using the $__interval essentially controls the Group By clause so that returned values represent no more than the number of pixels that can be displayed in the trend tool (Grafana). $timeFilter is the time range from the Grafana trend tool, which in my case is the 30 day period. Stress Test Break Point: At the 30 Day query test level, Influxdb service stops. Prior to this, Influxdb is able to “grind” through the queries and return results.

Any further thoughts on how to better configure the service would be greatly appreciated.